SIMULTANEOUS REAL-TIME PRESENTATION 
OF FINANCIAL INFORMATION 



RELATED APPLICATIONS 

The following applications are related by subject matter and are hereby 
incorporated by reference: 

Application Serial No. 09/475,634 entitled "Real-Time Presentation of 
Financial Information," currently pending. 

Application Serial No. 09/475,636 entitled "Method of Accessing 
Financial Information," now abandoned. 

Application Serial No. 09/476,073 entitled " Method of Account Holder 
Access to Financial Information," now abandoned. 

Application Serial No. 09/475,538 entitled "Method of Charging for 
Access to Financial Information," now abandoned. 

BACKGROUND 

A user of financial system must log-on to the financial system before 
the user performs an action such as an inquiry or a transaction. If the user 
wishes to access another financial system, the user must log-on to the second 
financial system. Each financial system usually has its own menus and 
presents information in its own manner. Thus, a user, who wishes to access 
multiple financial systems, must remember multiple log-on user IDs and 
passwords and learn to operate each financial system. This process is time 
consuming and difficult. If the user wishes to access information from multiple 
financial systems, the user access each financial system serially, create time 
lags between accesses. Additionally, some financial systems charge fees 
based on the user's actions. If a database provider, also called a data 
warehouse company, maintains the database for the financial institution and 
provides access to the users, the database provider charges access fees. 
However, access and fees are limited to fees associated with accessing the 
databases that the database provider maintains. 
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BRIEF SUMMARY 

The present invention is defined by the following claims, and nothing in 
this section should be taken as a limitation on those claims. By way of 
introduction, the preferred embodiments describe below include a method of 
5 simultaneously presenting user specific real-time financial information 

includes authenticating a user, for example by using a user-id and password. 
Then receiving an input from the user indicating the shareholder of interest. 
The user is then presented with a list of the shareholder's account information. 
The shareholder account information can be retrieved from several different 
10 record keeping systems. The record keeping systems can be maintained by 

different entities and can store the respective account information in different 
formats. 

The shareholder account information can be retrieved by broadcasting 
an account inquiry to the record keeping systems or by using a cross- 
15 reference table that indicates which record keeping systems the shareholder 

has accounts with. A combination of the broadcast and cross-reference table 
can be used. 

Once the shareholder account information is presented, the user can 
select an account, for example by a hyperlink tag, and receive detailed 
20 information about that account. 

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS 

The present invention is illustrated by way of example and not limitation 
in the accompanying figures. In the figures, like reference numbers indicate 
25 identical or functionally similar elements. Additionally, the left-most digit(s) of 

a reference number identifies the figure in which the reference number first 
appears. 

Figure 1 is a representation of an embodiment of a system for 
accessing financial information; 
30 Figure 2 is a representation of an embodiment of databases stored in a 

financial record keeping system; and 
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Figure 3 is a diagram of an embodiment of a screen with multiple 
regions displaying real-time financial information from multiple record keeping 
systems simultaneously; 

Figure 4 is one embodiment of a screen with a portfolio view; 
5 Figure 5 is a representation of a bill showing the charges; 

Figure 6 is a representation of an embodiment of a system for 
accessing financial information; 

Figure 7 is a representation of an embodiment of a method of 
accessing financial information; 
10 Figure 8(a) is a representation of an embodiment of a screen for 

signing-on to the system of Figure 1 ; 

Figure 8(b) is a representation of an embodiment of a screen with a list 
of financial institutions that a user may access; 

Figure 8(c) is a representation of an embodiment of a financial 
15 institution menu window; 

Figure 8(d) is a representation of an embodiment of a shareholder 
account history; 

Figure 9 is a representation of an embodiment of a header portion of a 
message; 

20 Figure 10 is a representation of an embodiment of error codes for 

Figure 4; 

Figure 1 1 is a representation of an embodiment of a request message; 
Figure 12 is a representation of an embodiment of a response 
message; 

25 Figure 13 is a representation of an embodiment of a method of 

enrolling a user for accessing a financial institution; 

Figure 14(a)-14(f) are representations of windows for enrolling a new 
user or adding access to additional financial institutions; and 

Figures 15A-15L are flow charts depicting the operation of alternate 
30 embodiments of Figure 1 . 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A financial intermediary, such as a stockbroker, needs to access his 
clients' financial information. The clients' financial information often includes 
information about accounts at different mutual fund companies and that 
information is often maintained on different record keeping systems. The 
present invention allows the financial intermediary to view substantially 
simultaneously the clients' financial information from multiple record keeping 
systems with one user ID and password. This significantly simplifies the 
process of accessing the clients' financial information. 

DST Systems' Vision Mutual Fund Gateway (Vision) incorporates 
some, but not all, of the features describe below. Vision includes an 
interactive internet site, www.dstvision.com, that allows financial 
intermediaries to access financial information in a real-time environment. 
Financial intermediaries include broker/dealers, financial advisors, financial 
representatives, and other. The financial information accessible through 
vision includes fund, shareowner account, and dealer information. 
Specifically, the financial information includes real-time information such as 
shareholder positions, account options, transaction histories, fund pricing and 
yields. Further, the financial information includes fund information, net asset 
value summaries, distribution information, order information, dealer 
information, branch information, representative information, and account 
summaries by representatives or advisor number. Vision also supports 
information inquiry that include inquiries to account information by dealer 
account number, fund account number, shareholder name, tax identification 
number or social security number, and representative or advisor number. 

Vision provides access to all authorized fund groups via a single log- 
on, real-time fund and shareholder account information, transaction 
processing, and new account creation. Vision is accessible via an intranet or 
other networks, such as the Internet. 

Figure 1 is a representation of an embodiment of a system 100 for 
accessing and presenting financial information. The system 100 includes a 
computer 104, a server 106, and first and second record keeping systems 
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108, 110. The computer 104 includes a personal computer, terminal, laptop, 
palmtop, mainframe, or other device capable of communicating with the 
server 106. In an embodiment, the computer 104 includes an output device 
such as a monitor, a diskette drive, or a printer. The computer 104 includes an 
5 user interface for receiving inputs from the user and providing outputs to the 

user. 

The server 106 communicates with the computer 104 and a plurality of 
record keeping systems, for example the first record keeping system 108 and 
the second record keeping system 110. In an embodiment, the server 106 

10 includes an access module and an user interface module. The access 

module is capable of accessing a plurality of independent substantially real- 
time financial record keeping databases. The user interface module is 
capable of receiving inputs from a user and presenting results to a user. In an 
other embodiment, the server 106 includes a user interface, record keeping 

15 system interface, and a router. The user interface communicates with an 

authorized user and receives user requests from the user and transmits user 
responses to the user. The record keeping system interface accesses 
information on first and second record keeping systems that maintain 
respective first and second account information in different formats. The 

20 router routes user requests to the first or second record keeping system as 

appropriate. 

In a preferred embodiment, the first and second record keeping 
systems 108, 110 are owned by different entities, such as mutual fund 
companies. The server 106 may be owned by the same entity that owns one 

25 of the first and second record keeping systems 108, 1 10 or other entity. An 

example of a record keeping is DST Systems' TA2000®. 

In an embodiment, the records stored in the first and second record 
keeping systems 108, 110 are stored in different formats. In another 
embodiment, the record keeping systems 108, 110 have different data 

30 structures or different operating systems. The record keeping systems 108, 

110 are controlled by a.) a data warehouse company that maintains the data 



for a financial institution, b.) the financial institution maintains their own data 
warehouse, or c.) another entity. 

The records stored in the first and second record keeping systems 108, 
110 include account information, such as mutual fund accounts, annuities, 
and other financial information, and fund information, such as yield to date, 
and net asset value. The records may include other account and/or fund 
information. 

A user at the computer 104 accesses the information stored on the first 
and second record keeping systems 108, 1 10 through the server 106. 
Preferably the user is a financial intermediary. The computer 104 accesses 
the server 106 via the Internet, a direct connect, an intranet, or other 
mechanism. Preferably, the computer 104 accesses the server 106 via the 
Internet using the secure socket layer protocol (SSL). Preferably, the first and 
second record keeping systems 108, 110 maintain real-time financial 
information on accounts and funds. 

The server 106 maintains several databases that track relationships. 
The relationships are stored in tables, database, flat files, or with other 
mechanisms. These databases include authentication information, such as 
the operator ID and password that are used during user log-on. The 
databases include the relationship between the operator ID and remote 
systems operator IDs. 

For example, a user signs onto the system 100 using an operator ID 
and password. When that user accesses a record keeping system, the server 
106 determines an second ID for the record keeping system associated with 
the operator ID and password. The server 106 sends a request for 
information to the record keeping system with the second ID, that is the 
operator ID or remote system operator ID. Thus, a user need only remember 
the operator ID and password for the server 106, and need not know the IDs 
for the record keeping systems. Each record keeping system uses its own ID 
or the server operator ID. 

The server 1 06 also maintains information representing the 
relationships between operator ID and the user's financial companies. For 
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example, after a user logs-on to the server 106 with an operator ID and 
password, a list of fund families is presented. The list includes the funds that 
the user is allowed to access. Fund families are also called fund companies, 
mutual fund companies, and management companies. 
5 The server 106 also maintains a routing table that represents the 

relationship between the fund companies and the record keeping system 
where their financial data is stored. This table is used to route request to 
record keeping systems. Financial data includes account data and fund data. 
For example, when the server 106 receives an inquiry for fund 

10 information, the server 106 determines which record keeping entity has the 

data for that fund. A request for an action is then transmitted to that record 
keeping entity. Preferably, the request includes an action code or action 
indicator that indicates an action to be taken. Likewise, the response includes 
a response code or response indicator that indicates the status of the action. 

15 In one embodiment, the record keeping systems are directly connected with 

the server 106, and the routing includes port identifications, where each 
record keeping system is associated with a port. Preferably, the server 106 
communicates with the first and second record keeping systems via a secure 
access, such as a direct connection. In this example, the server 106 is a 

20 trusted system and the first and second record keeping systems do not 

require the server 106 to be authenticated. The action can include an inquiry, 
a transaction, or other activity related to an account or fund. In a preferred 
embodiment, the record keeping systems are directly connected with the 
server 106, and the routing includes port identifications, where each record 

25 keeping system is associated with a port. Preferably, the server 106 

communicates with the first and second record keeping systems via a secure 
access, such as a direct connection. In this example, the server 106 is a 
trusted system and the first and second record keeping systems do not 
require the server 106 to be authenticated. 

30 Financial intermediaries are often associated with dealer, branch, and 

representative identifiers. In a preferred embodiment, the record keeping 
system may maintain the relationships between each operator ID and the 



operator's dealer, broker, and representative. The dealer, broker, 
representative information is used to control access to account and fund 
information on the record keeping system. For example, a representative has 
access to his clients' account information. A branch manager has access the 
account information of the representatives in that branch. A dealer has 
access to the account information of the representatives at each branch. 

Alternatively, the server 106 maintains the relationships between a 
user's operator ID and the dealer, branch, and representative associated with 
the operator ID. The dealer, branch, and representative is provided to the 
record keeping system in a request for information or a request for a 
transaction. 

In a preferred embodiment, the first record keeping system 108 is a 
TA2000® system and the server 106 is a FAN® switch and a Stratus® 
server. 

Optionally, a user at the computer 104 also accesses a record keeping 
system independently of the server 106. For example, direct connection is 
offered by some record keeping systems. 

After the server 106 transmits a request for information to a record 
keeping system, the server 106 receives a response from the record keeping 
system. The server 106 evaluates the response and selectively presents a 
portion of the response to the use. The response includes the requested 
information or an error message. Portion of multiple responses can be 
presented to the user serially or substantially simultaneously. 

In an embodiment, the server 106 executes a computer program(s) 
embodied on a computer-readable medium capable of presenting real-time 
financial account information to authenticated users. The computer 
program(s) includes a security module, a communication module, and a 
presentation module. The security module authenticates users for example 
with a user ID and password. The communication module communicates with 
at least first and second record keeping systems. The first and second record 
keeping system storing at least first and second real-time financial accounts in 
respective first and second storage formats. The first storage format being 



different from the second storage format. The communication module 
sending first and second requests for real-time financial account information 
to the respective first and second record keeping systems and receiving first 
and second responses from the respective first and second record keeping 
systems. The presentation module presents a portion of the first and second 
responses serially or substantially simultaneously. 

In another embodiment, the server 106 includes an access module and 
a user interface module. The access module accesses a plurality of 
independent substantially real-time financial record keeping databases. The 
user interface module receives requests and presenting results relating to the 
plurality of independent substantially real-time financial record keeping 
databases. The user interface module presents a uniform set of user displays 
for accessing the independent substantially real-time financial record keeping 
databases. Some of the modules described above may be implemented 
separate from the server 106, such as on the computer 104. 

The user provides authentication information, such as a user 
identification and password. Preferably, the user establishes an account by 
accessing an Internet based site and entering a user ID and password. Then 
the user enters contact and verification information that includes user's name, 
address, social security number, phone number, e-mail address, and other 
information. During subsequent accesses, the user enters the user ID and 
password. When a user has forgotten a user ID or password, a message 
containing the forgotten information can be sent to a secure e-mail system, 
such as DST Systems' ePriority system. Alternatively, a user enters 
information such as social security number, and/or date of birth to verify their 
identity, and the forgotten information is presented to the user. Once 
authenticated, the user enters an identification or identifications of the account 
holder(s) that the user wishes to get information about. A request for account 
information associated with the account holder identification(s) is sent to 
various record keeping systems. A response is received from those record 
keeping systems. 
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The request for account information is sent to the record keeping 
systems known to have information associated with the account holder 
identification. This can be determined by using a cross-reference table that 
indicates which record keeping systems have information associated with a 
given account holder's identification. This cross-reference table is created 
after the user enrolls with the server 106. Preferably, the record keeping 
systems or the financial institutions provide the cross-reference information to 
server 106. Some record keeping systems or the financial institutions may 
choose not provide the cross-reference information. In this case, they receive 
a broadcast request for information every time a request for information is 
sent. 

Alternatively, this cross-reference between account holder's 
identification and accounts is created during the enrollment process where 
each fund company is identified by the user. A cross-reference between fund 
company and record keeping system is used to create the cross-reference 
table between account holder identification and record keeping system. 

Alternatively, the cross-reference table is created in whole or in part 
based on previous responses to broadcast requests for information. That is, a 
request for account information associated with an account holder 
identification is sent to some or all of the known record keeping systems. The 
broadcast is performed periodically or on an ad hoc basis. The responses 
indicate which record keeping systems have account information associated 
with them. This information is used to update the cross-reference table. This 
is an example of a dynamic cross-reference table. 

The requests for account information are transmitted based on a cross- 
reference table and/or based on a list of record keeping systems or financial 
institutions that are known not to be included in cross-reference table. Some 
entities maintaining record keeping systems or financial institutions may prefer 
to receive a request every time a request is made and then determine if the 
requested account information is available instead of maintaining cross- 
reference tables. 
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While financial intermediaries accessing mutual fund accounts have 
been used as an example, the present invention as defined by the claims can 
be applied to other financial accounts such as annuities, credit accounts, bank 
accounts, and other financial accounts. 

Optionally, the system 100 allows the user to maintain multiple 
portfolios having different accounts within each portfolio. For example, a user 
has a first portfolio with accounts that are part of a 401 K plan, a second 
portfolio with accounts that are not part of a 401 K plan, and a third portfolio 
with the accounts in the first and second portfolios. Each portfolio includes 
accounts from one or more different financial institutions, and the account 
data is maintained by the same or different record keeping companies. The 
user edits, deletes, and creates new portfolios as desired. 

In one embodiment, the system 100 accesses no-load mutual fund 
data from a plurality of financial institutions maintained on a plurality of record 
keeping systems. The user accesses the account information by navigating a 
set of screens. A single user ID and password gives the user access to the 
plurality of accounts. The user performs inquiries, transactions, and account 
servicing for each of the accounts. Optionally, a consolidated view of the 
user's accounts is presented. 

Optionally, the provider of the services described above charges fees 
for accessing the account information. It is preferred that the fees be charged 
to the financial institutions. Alternatively, the account holder, a third party, or 
a combination thereof is also charged. Possible fees include: setup fees, 
monthly operator ID fees, per view fees, per transaction fees, registration fees 
(also called new account fees), monthly minimum fees, and other fees. 
Optionally, advertising fees are charged for advertisements that appear on a 
screen. 

For example, the fee are as follows: inquiry view fee $0.05, user ID fee 
$5 per month per financial institution, purchase fee $0.50, redemption fee 
$0.50, exchange fee $0.50, new account fee $3, account position inquiry 
$0.05, account history inquiry $0.05, portfolio position inquiry $0.05, 
transactions $0.50. Alternatively, the fees are inquiry views $0.05 and 
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transactions $0.50. Different fees, combinations of fees and/or fee amounts 
may be used. 

The user performs actions including inquiry, transactions, and account 
maintenance. The inquiry actions include portfolio positions (shares price, 
market value, etc.), portfolio history (transactions across accounts, etc.), 
account details (registration, dividend options, account options, etc.), and 
account history (transactions within an account). The transaction actions 
include purchases by an automated clearing house (ACH) to new or existing 
accounts, redemption by ACH, withdraws by check, withdraws by wire, 
exchanges to new or existing accounts within the same fund family, and 
exchanges to new or existing accounts across fund families. Account 
maintenance actions include ordering duplicate statements, viewing 
statements on-line, ordering duplicate tax forms, viewing tax forms on-line, 
viewing year-end information, ordering checkbooks, changing address, 
updating distribution options, adding/updating systematic agreement files, 
updating bank information, establishing new accounts, and averaging costs. 
Other inquiries, transactions and/or account maintenance actions may be 
provided. 

In a preferred embodiment, the system provides financial planning 
capabilities including asset allocation graphs by investment and Morningstar 
data or other value service data. 

Optionally, the server 106 charges for access to real-time financial 
information stored on independent systems and includes an access module 
and a fee module. The access module provides user access to a first real- 
time financial account on a first system and a second real-time financial 
account on a second record keeping system. The first account being 
associated with a different financial institution then the second account. The 
fee module calculates at least first and second fees based on accesses to the 
respective first and second financial institutions. The fees are a function of 
user initiated activities. Optionally, the fee module includes a billing module 
that transmits a bill electronically. 
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Figure 2 is a representation of an embodiment of databases stored in a 
financial record keeping system. The record keeping system format 200 
includes information on fund families, 202, 204. The first fund family 202 
includes information related to a plurality of accounts in the accounts data 206 
and information related to a plurality of funds in the funds data 208. The 
second fund family 204 includes information related to a plurality of accounts 
in the accounts data 210 and information on a plurality of funds in the funds 
data 212. Preferably, the funds include mutual funds and annuities, however, 
the invention also includes stocks, bank accounts, or other financial accounts. 
The funds data 208, 212 includes such information as daily yields, year to 
date performance, total value, and other information. 

In one example, the record keeping systems 200 is the first record 
keeping system 108 (Figure 1) and is maintained and controlled by DST 
Systems, the first and second fund families 202, 204 are respectively the First 
Fund Company and the Second Fund Company. The First Fund Company 
has a thousand accounts each owned by one or more account holders. The 
First Fund Company has twenty funds, such as a domestic growth fund, an 
international growth fund, a money market fund, and a balanced fund. The 
second record keeping system 110 (Figure 1) is maintained by a mutual fund 
company and includes information on only the mutual fund company's mutual 
funds and accounts. 

The fund families are mutual fund families, or other grouping of 
accounts usually at the same financial institution. The accounts represent 
annuities, money markets, margin accounts, bank accounts, credit accounts, 
and/or other accounts. 

Figure 3 is a diagram of an embodiment of a screen 300 includes a 
balance area 302, a first account area 304, and a second account area 306. 
Additional account areas will be included if more accounts are retrieved. The 
screen 300 may be presented to a user on the computer 104 (Figure 1) on a 
monitor. The balance area 302 that includes information, such as, a summary 
of information in the first and second account areas 304, 306. Optionally, the 
balance areas 302 also includes information relating to the account holder 
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such as the account holder's name, address, phone number, and other 
information. The first and second account areas 304, 306 each include 
information from different record keeping systems and/or account information. 
In the embodiment shown in Figure 3, the first account area 304 shows 
information relating to the "First Fund Company". The account holder, "John 
Smith", has two accounts with First Fund Company. These accounts have the 
same account number "0001 11" and different fund names "Growth" and "Tech 
Fund." Account information about John Smith's accounts include his tax ID, 
for example his social security number, the number of shares, and the 
balance. Other account information can also be included. 

Once screen 300 is presented to the user, the user receives further 
details of any account by selecting the desired account. The desired fund is 
selected by activating a hyper link on the display, by entering the account 
information, or by any other means. 

Preferably, the account information shown in Figure 3 is substantially 
real-time financial information. 

While Figure 3 shows a first record keeping system with a first and 
second fund family having account data and fund data, other embodiments 
may have similar or different structure and include similar or different 
information. For example, the fund families are replaced with annuity family, 
or accounts at a particular financial institution that may include some mutual 
funds, some annuity funds, some brokerage accounts, and/or other accounts. 
In these cases, the account data contains information about the accounts. 
However, the type of information may vary based on the type of account. 

The second account area 306 shows information for John Smith at the 
Second Fund Company. 

For example, the screen 300 having substantially real-time financial 
information that is stored on a first record keeping system and a second 
record keeping system, the first record keeping system being different from 
the second record keeping system is accessed by the following method. 

The server 106 (Figure 1) receives an account holder identification 
from a user. The account holder identification is associated with a first 
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account information stored on the first record keeping system and a second 
account information on the second record keeping system. The server 106 
transmits first and second requests to the respective first and second record 
keeping systems. The first and second requests request information 
associated with the account holder identification. The server 106 receives 
first and second responses from the respective first and second record 
keeping systems. The first and second responses include substantially real- 
time financial information associated with the account holder identification. 
Optionally, the server 106 presents a portion of the responses to the user. 

Optionally, the first request is transmitted based on a cross-reference 
of account holder identification to record keeping systems and the second 
request is transmitted based on a list of record keeping systems known to be 
absent from the cross-reference. For example, the first request is transmitted 
based on Table 1 and Table 2 and the second request is transmitted based 
on Table 3. 

Table 1 is an embodiment of a cross-reference table showing 
relationships between account holder, tax ID, first and second account holder 
id, and record keeping system. Table 1 shows an account holder that has 
different account holder identifications for each record keeping system. 



Account 
Holder 


Tax ID 


First Account 
Holder ID 


Second 
Account 
Holder ID 


Record 

Keeping 

System 


John Smith 


123-45-6789 


JS0000123 


JS0000123 


First RKS 


John Smith 


123-45-6789 


JS0000123 


JS0000123 


First RKS 


John Smith 


123-45-6789 


JS0000123 


XYZ00999 


Second RKS 


Mary Jones 


111-22-3333 


MJ101010 


MJ101010 


First RKS 


Mary Jones 


111-22-3333 


MJ101010 


444555666 


Second RKS 


Mary Jones 


111-22-3333 


MJ101010 


444555666 


Third RKS 


Mary Jones 


111-22-3333 


MJ101010 


87654321 


Fourth RKS 



Table 1 

Table 2 is an embodiment of a cross-reference table showing 
relationships between account holder, tax ID, second account holder ID, 
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financial institutions, and account identifier. Table 2 shows that an account 
holder may have several accounts at one or more financial institutions and the 
account information is stored on different record keeping systems as indicated 
in Table 1 . 



Account 
Holder 


Tax ID 


Second Account 
Holder ID 


Financial 
Institution 


Account 
Identifier 


John Smith 


123-45-6789 


JS0000123 


ABC Funds 


1000333 


John Smith 


123-45-6789 


JS0000123 


CDF Funds 


2200333 


John Smith 


123-45-6789 


XYZ00999 


XYZ Funds 


990099 


Mary Jones 


111-22-3333 


MJ101010 


ABC Funds 


1000111 


Mary Jones 


111-22-3333 


444555666 


PDQ Funds 


2234343 


Mary Jones 


111-22-3333 


444555666 


DEF Funds 


333444 


Mary Jones 


111-22-3333 


87654321 


HIJ Funds 


44440001 



Table 2 



Table 3 is an embodiment of a table showing relationships between 
record keeping systems and financial institutions. Table 3 shows the record 
keeping systems and financial institutions that are accessible to the server 
106 (Figure 1) but are do not maintain their accounts in the cross-reference 
tables Table 1 and Table 2. The record keeping systems and financial 
institutions in Table 3 receive a broadcasted request every time the server 
request account information. 

It is preferred that all financial institutions whose account information is 
maintained on a given record keeping system maintain the cross-reference 
tables Table 1 and Table 2. In an alternative embodiment, only some 
financial institutions on a given record keeping system choose to not maintain 
the cross-reference between account holder and financial institutions and 
associated record keeping systems. While the record keeping systems or the 
financial institutions maintain the cross-reference between account holder and 
financial institutions and record keeping systems, the server 106 (Figure 1) 
would has a copy of the cross-reference table for routing requests. While 
maintenance of the cross-reference is performed by the record keeping 
system or the financial institution, however, the server 106 may also maintain 
the cross-reference table. For example, in an embodiment with a dynamic 
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cross-reference table, the server 106 is constantly or periodically updates the 
cross-reference table. 



Record Keeping System 
(Broadcast) 


Financial Institutions 


Fifth RKS 


All Financial Institutions 


Sixth RKS 


All Financial Institutions 


Seventh RKS 


All Financial Institutions 


Second RKS 


TUV Fund Company, LMN Fund Company, and 
AAA Annuity Company 



Table 3 



Figure 4 shows a screen 400 with a portfolio view. The screen 400 
includes a title area 402, a portfolio selection area 404, a portfolio data area 
406, a portfolio option area 408, and a message area 410. 

The title area 402 includes an application title, for example "Vision 
Direct" and a window title, for example "Portfolio View." The portfolio 
selection area 404 allows the user to select a portfolio. 

The portfolio data area 406 includes various information relating to the 
user's accounts. In one embodiment, the portfolio data area 406 includes the 
fund name, account number, current price, daily change in dollars per share, 
daily percentage change, number of shares, and current market value. The 
portfolio data area 406 may include other information about the accounts in 
the portfolio. The portfolio data area 406 also includes a portfolio total that 
represents the total value of the accounts displayed. Additionally, totals for 
the accounts in each financial institution may be included. In one 
embodiment, the portfolio data area 306 includes a date field that allows the 
user to access the information as of a specified date. 

In one embodiment, the portfolio option area 408 includes options to 
view a portfolio history, setup a new portfolio, and change a portfolio. 

The message area 410 includes instructions or messages for the user. 
For example, the instructions include instructions on how to view account 
details, how to view fund information, and how to visit a fund family's web site. 

Optionally, other screens display various types of account and fund 
information. 
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Figure 5 is a representation of a bill 500 that includes a header area 
502, an identifier area 504, and a charges area 506. The header area 502 
indicates the source of the bill, "Vision Mutual Fund Gateway" and the type of 
bill, "Monthly Billing Summary Report." The identifier area 504 includes such 
information as the report number, source program, job, system, corporate 
billing ID, management company code, and billing period. The charges area 
506 includes summary data on the charges for the period identified in the 
identifier area 504. The charges area 506 includes the number of action and 
the charges for those actions. The actions include views, vision IDs, 
purchases, redemptions, exchanges, and new accounts. The calculation of 
the charges associate with the actions are described below. 

Revenue is generated for the entity providing access to financial 
information. For example, the entity is an entity operating the server 106 
(Figure 1), provides access to the user via the Internet, and providing access 
to various record keeping systems. Some of the record keeping systems may 
be provided by the same entity as the server 106 while other record keeping 
systems are provided by other entities. Each record keeping system 
maintains data on one or more financial accounts, such as mutual fund 
account in one or more financial institutions. Optionally, the mutual fund 
company maintains the record keeping. 

The service provider, usually the company maintaining the server 106 
(Figure 1), generates revenue by charging one or more of the following fees: a 
setup fee, a monthly operator ID fee, a per view fee, a per transaction fee, a 
registration fee (also called a new account fee), a monthly minimum fee, and 
other fees. 

The setup fee is charged for establishing access to a new financial 
institution through the server 106 (Figure 1). For example, if a mutual fund 
company wishes to provide access to accounts through the server 106, the 
service provider charges a setup fee. The setup fee may be any amount, 
such as $1 ,000, $5,000, $1 ,000,000, or another amount. The setup fee may 
be varied based on whether the financial institution is maintaining data on a 
record keeping system maintained by another entity or is maintaining its own 
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data. For example, the setup fee for a financial institution maintaining its own 
data is half of the regular setup fee. In a preferred embodiment, the setup fee 
is $5,000 for new customers and $2,500 for existing customers. Preferably, 
the setup fee is charged to the financial institution. 

The operator ID fee, also called user ID fee and user identification fee, 
is charged periodically, for example monthly, for each operator that has 
access to each account. If an operator has access to more than one account 
(or fund), then that operator ID fee charged for each account. 

The operator ID fee is any amount, including $0.05, $0.50, $1 , $2, $3, 
$4, $5, $100, or more. Discounts can be provided for higher volume financial 
institutions. The discounts are based on a graduated fee basis in one 
embodiment. For example, the first 500 operator IDs are $5/ea. per month, 
the next 500 operator IDs $4/ea. per month, the next 1000 operator IDs are 
$3/ea. per month, the next 1000 operator IDs are $2/ea. per month, and each 
operator ID beyond 3000 is free. In this example, the maximum fee would be 
$9,500/mo. 

The view fee is charged for viewing the result of an inquiry. The inquiry 
may include information from several accounts and only one view fee is 
charged. Alternatively, the view fee is based on the number of accounts 
accessed. For example, the view fee is $0.01 , $0.05, $0.10, or an other 
amount per view. Preferably, the view fee is charged to the financial 
institution. 

The transaction fee is charged for each transaction performed. 
Transactions include purchases, redemptions, exchanges, and/or other 
transactions. The transaction fee is $0.01 , $0.5, $0.50, or another amount per 
transaction. Preferably, the transaction fee is charged to the financial 
institution. 

The new account fee, also called a registration fee, is charged for each 
new account. In a preferred embodiment, a single new account fee is 
charged when multiple accounts for the same shareholder or owner are 
established at the same time in the same mutual fund family. The new 
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account fee is $0.50, $1 , $3, $5, or an other amount. Preferably, the new 
account fee is charged to the financial institution. 

The monthly minimum fee is charged when the total of the other 
monthly fees are below a desired level. For example, the monthly minimum 
fee is $100, $500, $1 ,000, or an other amount. The monthly minimum is 
based on a per user ID basis, a per fund basis, and/or a per financial 
institution basis. Optionally, the monthly fee is based on the size of the 
financial institution, the number of accounts, and/or other factors. Optionally, 
the monthly minimum varies depending on whether the server 106 (Figure 1) 
provide financial transactions for the financial institution. For example, the 
monthly minimum fee is $500 if the server 106 provide financial transactions 
and responds to inquiries and $0 if the server just responds to inquiries. 

Discounts may be provided for any type of fee or for any combination 
of fees. Minimum and maximum fees may be assessed for any type of fee or 
combination of fees. The fees for any type of fee may be graduated. The 
graduated fees can increase or decrease as the use of the server increases. 
Preferably, the fees are charged to the financial institution being accessed. 
However, in the alternative, the user or a third party is charged. 

Figure 6 is another representation of an embodiment of a system 600 
for accessing and presenting financial information. The system 600 includes 
a plurality of computers 601 , 602, 603, each running a standard WEB browser 
or other communication program for accessing the server 605. Each 
computer 601 , 602, or 603 comprises a personal computer, terminal, laptop, 
palmtop, mainframe, or other device capable of communicating with the 
server 605. The computers 601 ,602, 603 access the server 605 via an 
intranet or other network, such as the Internet, or via a direct communication 
line. The server 605 communicates with the computers 601-603 and a 
plurality of record-keeping systems, for example, the first record-keeping 
system 608 and the second record-keeping system 610. The computers 
601-603 may execute an application for communicating with the server 605. 
The server 605 may execute an application or group of applications for 
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communicating with the computers 601-603 and the first and second record- 
keeping systems 608, 610. 

According to one aspect, the first and second record-keeping systems 
608, 610 are owned by different entities, such as fund companies. The server 
605 may be owned by the same entity that owns one of the first and second 
record-keeping systems 608, 610. 

The records stored in the first and second record-keeping systems 608, 
610 are stored in different formats, but a same format may be used. The 
record-keeping systems 608, 610 have different or the same data structures, 
and/or operating systems. The record-keeping systems 608, 610are 
controlled by a data warehouse company that maintains the data for a 
financial institution, or the financial institutions. 

The records stored in the first and second record-keeping systems 608, 
610 include account information, such as mutual fund accounts, annuities, 
and other financial information, and fund information, such as yield to date, 
net asset value. 

A user at a computer 601 , 602, 603 accesses the information stored on 
the first and second record-keeping systems 608, 610 through the server 605. 
It is preferred that the users include financial intermediaries. The server 605 
maintains several databases that track relationships. The relationships are 
stored in tables, database, flat files, or with other mechanisms. These 
databases include the user ID and password used for user authentication or 
log-on. The databases include the relationship between the user ID and 
record-keeping systems user IDs. For example, a user signs-on to the 
system 600 using a user ID and password. When that user accesses a 
record-keeping system 608, 610, the server 605 determines an internal ID for 
the record-keeping system 608, 610 associated with the user ID and 
password. In an alternative embodiment, the server 105 determines an ID 
and password for the record-keeping system associated with the user ID and 
password used to sign-on to the system 600. The server 605 sends a 
request for information to the record-keeping system with the a user ID, which 
is the system user ID or the internal user ID. Thus, a user need only 
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remember the user ID and password for signing-on to the server 605, and 
need not know the user IDs for the record-keeping systems. Each record- 
keeping system may know the user by a different internal user ID or use the 
same user ID as the server 605. 

The server 605 also maintains the relationships between the system 
user ID and the financial companies that the user can access. For example, 
after a user logs-on to the server 605 with a user ID and password, a list of 
fund families is presented. The list includes the funds that user is allowed to 
access. In one aspect, the list includes just the funds accessible to the user. 
Fund families also comprise fund companies, mutual fund companies, 
financial institutions, and management companies. The list of authorized 
fund families is based on the relationships stored in the database. 

The server 605 also maintains a routing table. The routing table 
includes the relationship between the fund companies and the record-keeping 
system where their financial data is stored. Financial data includes account 
data and fund data. For example, when the server 605 receives an inquiry 
for fund information, the server 605 determines which record-keeping 
company has the data for that fund. A request is then transmitted to that 
record-keeping company. In a preferred embodiment, the record-keeping 
systems 608, 610 are directly connected with the server 605, and the routing 
includes port identifications, where each record-keeping system is associated 
with a port. 

Financial intermediaries are often associated with dealer, branch, and 
representative identifiers. The record-keeping system may maintain the 
relationships between user ID and dealer, broker, and representative. The 
user ID may be the user ID used to log-on to the server or the internal user ID 
assigned by a record-keeping system. 

Alternatively, the server 605 maintains relationships between a user's 
user ID and the dealer, branch, and representative associated with the user 
ID. The dealer, branch, and representative are provided to the record- 
keeping system in a request for information or a request for a transaction. 
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The server 605 dynamically builds the HTML pages that are sent to the 
clients' browsers. The server 605 decodes a request from a client's browser 
into a transaction request and forwards the request to the Protocol Converter 
and Switch 606. The switch 606 determines, by referring to the cross- 
reference database 612, which record-keeping system has the requested 
data. The switch 606 translates and forwards the request into a format and 
protocol that the target record-keeping system supports and forwards the 
request to the target record-keeping system for processing. Once the record- 
keeping system has satisfied the request, it sends a response to the switch 
606. The switch 606 converts the response into a transaction response and 
sends the response to the server 605. The server 605 decodes the 
transaction response and dynamically builds the HTML pages to be delivered 
and displayed in the client's browser. The switch 606 handles data 
translations, for example between ASCII and EBCDIC. 

Referring now to Figure 7, a flow diagram 700 of the method of 
accessing specific information associated with a financial institution is shown. 
When a user signs-on to the system of Figure 1 , the server 105 sends the first 
user ID and password for authentication in act 701 . The first user ID may be 
the Vision ID according to one embodiment. Figure 8(a) shows a sign-on 
window according to one embodiment. The system is secured by a user ID, 
which can be restricted at dealer, dealer/branch, and dealer representative 
access levels or by a tax ID. The type of security associated with a user ID 
will affect the account information displayed on computers 601 , 602, and 603. 
The password is encrypted and compared against the encrypted password. 

After password authentication, a list of financial institutions that the 
user is authorized to access is presented to the user. The list of authorized 
financial institutions is determined by referring to a cross-reference database 
maintained within a data base, such as the User ID Cross-reference Database 
612 (Figure 6). Figure 8(b) shows an example of a list of financial institutions 
from which the user may access financial information. To add additional 
financial institutions, the user may click the "Sign up for Vision" hyperlink on 
Figure 8(a) to go to Vision enrollment WEB site. 
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In act 702 (Figure 7), the user selects one of the financial institutions 
from the displayed list to request specific financial information. The switch 
606 determines in act 703 whether the requested financial information is on 
the first record-keeping system. The switch 606 refers to the cross-reference 
database of financial institutions to the user ID maintained in the User ID 
Cross Reference Database 612 (Figure 6). 

If the selected fund is on the first record-keeping system 704, the 
server 605 sends in act 705 a request to the first record-keeping system. This 
request includes a first identification code, which may be the system user ID. 
The server 605 then receives in act 706 a response from the first record- 
keeping system. The server 605 presents in act 707 the response to the user, 
via e-mail, fax, or postal mail. 

If, however, the requested financial information is on the second 
record-keeping system 708, the request for specific information received from 
the user is sent from the server 605 to the switch 606. In act 709, the switch 
606 determines an internal identification code from the cross-reference 
database if one has been assigned to the user. In act 705 the switch routes 
the request to the second record-keeping system. The request includes the 
second identification code. The second identification code includes the 
internal identification code or the first identification code. In act 706 the server 
605 then receives a response from the second record-keeping system. The 
server 605 presents in act 707 a portion of the response to the user. 

Figure 8(c) shows a financial institution menu window for Global Prime 
Investor Funds, which the user may select from the list in Figure 8(b) in one 
embodiment. This window provides options for accessing detailed information 
about the Fund Company. Figure 8(d) shows a "Shareholder Account 
History" screen displaying transaction history information for an account within 
the funds. Vision provides real-time, up-to-date fund and shareholder account 
information. 

Communications between the server 605 and the record-keeping 
systems 608, 600 are via messages. The messages have a unique identifier 
name and may have a method to match responses with the corresponding 
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requests. Each message, being a request or a response to a request, 
comprises a header portion and a data portion. For example, for accessing 
an Account History, the header and account history request data are sent to 
the record-keeping system associated with the financial information. In the 
response from the record-keeping system, the header and account history 
response data will be returned. 

Figure 9 shows an example of a header record 900 according to one 
embodiment. This header is sent with a request or response message. The 
header includes one or more: 

(1) length fields that indicate the length of the message (packet) 
and/or the length of data portion 901; 

(2) a transaction ID 902, for example ACCTHIST® VISION for the 
Account History request, that indicates a transaction to be performed; 

(3) the source of the a message 903; 

(4) a source tag 904, which should be returned in the response 
header; 

(5) the user ID 905 used to sign-on to the system or the internal 
user ID assigned by the second financial institution; and 

(6) error messages 906 used by the target system to indicate which 
error occurred. 

Figure 10 shows a list of error messages, which include error codes 
indicating whether: 

(1 ) a severe system error has occurred 1 001 ; 

(2) files are unavailable for read access 1002; 

(3) the user ID is not authorized 1003; and 

(4) the target fund or the system is unavailable to process the 
request 1004. 

Other fields and/or messages may be used. 

The data portion of a request defines the specific information the user 
is desiring to access. The data portion of request messages and response 
messages may be fixed or variable length. An exemplary list of a DST 
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request data portion in the Vision system is described on pages 34-133 of 
Appendix B. 

Figure 1 1 shows one embodiment of a data portion of a fixed length 
transaction message 600 for requesting an account history. The request data 
1 100 includes: 

(1) a first field 1 101 for identifying the selected fund; 

(2) a second field 1 102 for identifying a shareholder account ; and 

(3) a third field 1 1 03 for indicating an index for requesting additional 
accounts. 

Other fields and/or messages may be used. 

Figure 12 shows an example definition of a data portion of a response 
message 1200 sent by a record-keeping system in response to an account 
history request. The data portion 1200 includes various fields: 

(1 ) optionally, the type of transaction 1 201 ; 

(2) the number of shares 1 202; 

(3) the amount of the transaction 1203, preferably in dollars; 

(4) the cumulative share balance of an account 1204; 

(5) the date of the transaction 1205; and 

(6) a transaction description 1206. 
Other fields and/or messages may be used. 

According to another aspect of the present invention a method of 
enrolling a user for accessing financial information from a financial institution 
is presented. A user requesting access to financial information associated 
with a financial institution accesses an online sign-up. The sign-up procedure 
generates a user ID setup request e-mail that is automatically sent to the 
service provider. Upon receipt, the service provider forwards an authorization 
request to the appropriate financial institution(s) for approval. This request 
contains the pertinent information needed to verify the operator's request and 
the user ID. Other sign-up procedures may be used, such as in response to 
written or voice instruction. 

The financial institution replies to the request. The financial institution 
may choose to provide its own user ID; however, if none is provided, the 
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system user ID is used. If the financial institution chooses to provide its own 
user ID, this ID will be maintained on the cross-reference database 612 
(Figure 6). Thus a user is able to sign-on to the system with one user ID and 
password to access many accounts. 

Figure 13 shows one embodiment of a flow diagram 1300 of the 
enrollment process. In act 1302 a user requests access to financial 
information. In act 1304, the user is requested to provide certain information 
to the system 600 in Figure 6. The user information may be received via a 
standard client WEB browser running on one of the computers 601-603, via 
phone, via e-mail, or via postal mail. 

Figure 14(a) shows a screen for a new user enrollment or for adding 
additional funds to the list of authorized funds for an existing user, according 
to one embodiment. Figure 14(b) shows the new user window after the user 
has selected the icon labeled "New User Enrollment" 1401 in Figure 14(a). 
When the user clicks on the icon "Enrollment Forms" 1402, the enrollment 
form, as shown in Figure 14(c), appears. This form allows the user to select 
one or more of the access levels 1403-1406. The access levels include 
dealer level, branch level, representative level, and Tax ID level. Figures 
14(d)-14(f) show the windows for providing user information when the user 
selects the respective access levels 1403-1406. 

In act 1305 (Figure 13), the server 605 establishes a first user ID and 
password for the user based on the user information. The first user ID has a 
unique association with each individual financial institution or fund company 
that has been authorized for the user. This association allows the Fund 
Company's name to be listed on the main entry window or display after the 
user signs-on. The server 605 supplies the first user ID to the selected 
financial institution so that the financial institution applies the appropriate 
security and access control. Several different types of intermediaries use the 
system 600, so the system 600 supports different levels of account access. 
Preferably, accounts linked to the user are accessible with a single log-on. 

In act 1306 the switch 606 translates the request into a format and 
protocol that the financial institution supports and forwards the translated 
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request to the target financial institution. The financial institution processes 
the request and may authorize the user to access financial information, may 
decline access to financial information, may indicate that information supplied 
from the user is not correct, or may modify the user-specified access levels for 
accessing the target record-keeping system. The switch 606 receives the 
access authorization information from the financial institution in act 1308, 
converts the response into a system transaction response, and sends the 
converted response to the server 605. The server 605 decodes the 
transaction response. 

In optional act 1310 the target financial institution assigns an internal 
user ID for the user. The server 605 cross-references the system user ID with 
the internally designated user ID in a database 612 (Figure 6) in act 1312, 
such that the user just needs to know the system user ID when accessing the 
financial information from financial institutions associated with both first and 
second record-keeping systems. If, however, the financial institution chose 
not to assign an internal user ID 1316, the server 605 provides the system 
user ID to the user in act 1314, and the system user ID is used for future 
access of the financial institution associated with both the first and second 
record-keeping systems. The user uses one user ID and password to access 
both financial institutions, such as accessing TA2000® and non-TA2000 
financial institutions with the same user ID and password 

An example of the enrollment process discussed above for the Vision 
system is as follows. The DST receives a request from representative, Sarah 
Williams, for Vision access to the ABC financial institution, which is a non- 
TA2000 system. The DST sends the request to the ABC financial institution, 
and references Sarah's DST-assigned Vision User ID "VS00001693." The 
ABC financial institution chooses to assign Sarah an internal user ID 
"ABC0000067." DST cross-references these two IDs in the cross-reference 
database 612 (Figure 6). 

When Sarah Williams desires to access a specific financial information 
from the ABC financial institution, Sarah signs on to the Vision system 100, 
through the window shown in Figure 8(a), with the DST assigned Vision user 
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ID "VS00001693." As mentioned above, this Vision user ID provides Sarah 
automatic access to the ABC (non-TA2000) financial institution, by means of 
the cross-reference database 612 (Figure 6). 

In another example, when the DST receives a request from Sarah for 
Vision access to the XYZ financial institution, which is also a non-TA2000 
system, the DST sends Sarah's request to the XYZ financial institution, and 
references Sarah's DST-assigned Vision User ID "VS00001693." However, 
the XYZ financial institution chooses not to assign Sarah an internal user ID. 
The switch 606 (Figure 6) uses Vision User ID "VS00001693" for accessing 
the XYZ financial institution. When Sarah desires to access specific financial 
information from the XYZ financial institution, Sarah signs-on to the Vision 
system 600 (Figure 6) with the DST-assigned Vision User ID "VS00001693." 
As mentioned above, this Vision ID provides Sarah direct access to financial 
information from the XYZ (non-TA2000) financial institution. 

The authorization request, which is sent to a target financial institution, 
includes the user ID and the user information entered by the user, through the 
windows shown in Figures 14(c)-14(f), in one embodiment, such as the user's 
name, address, phone number, and the user-demanded access levels. 

The authorization response includes the user ID, access information, 
and the internal user ID. The access information may either include 
information confirming the access levels that the user had demanded, or 
information modifying the user-demanded access levels. For example, if the 
user had demanded a dealer number 123 and a representative number 345, 
the target financial institution may approve the dealer number 123, but may 
change the representative number to 678. 

The following appendices are hereby incorporated by reference: 
Appendix A, entitled "Vision Mutual Fund Gateway Training Guides" and 
Appendix B, entitled "Vision Mutual Fund Gateway External Funds Technical 
Manuals." 

While the examples provided above have mutual fund companies as 
the financial institutions, the invention is applicable to other financial 
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institutions such as those that deal with annuities, variable annuities, bank 
accounts, credit accounts, and bond funds. 

While preferred embodiments have been shown and described, it will 
be understood that they are not intended to limit the disclosure, but rather it is 
intended to cover all modifications and alternative methods and apparatuses 
falling within the spirit and scope of the invention as defined in the appended 
claims or their equivalents. 



